This PR is the sequel of #6517. This time, we are “flattening” the pinned-events cache, i.e. it extracts the pinned-event cache from the room cache to move it directly in Caches. The tree goes from:

graph TD;
    EventCache-->Caches;
    Caches-->RoomEventCache;
    RoomEventCache-->RoomEventCacheState;
    RoomEventCacheState-->PinnedEventCache;
    PinnedEventCache-->PinnedEventCacheState;

to:

graph TD;
    EventCache-->Caches;
    Caches-->RoomEventCache;
    Caches-->PinnedEventsCache;
    RoomEventCache-->RoomEventCacheState;
    PinnedEventsCache-->PinnedEventsCacheState;

Breaking Changes

First and foremost, PinnedEventCache is renamed PinnedEventsCache (plural form on Event) because it contains… multiple… events… hence the plural.

All methods related to pinned-events on RoomEventCache are removed, for example: RoomEventCache::subscribe_to_pinned_events (side note: funny how we have the plural here 🤪) is now PinnedEventsCache::subscribe.

EventCache now provides 1 new public method: pinned_events to lazily access to the PinnedEventsCache.

New Features or Bug Fixes

Because, yeah, we have new features coming with this refactoring!

• more related events — Until now, the pinned-events cache was storing some events relating to the pinned-events, such as: replacement (edit), or reference, but annotation (e.g. reaction) was missing. Now this is all supported thanks to the new extract_relation helper introduced in the previous PR. This is part of the new aggregator::aggregate_timeline_for_pinned_events pipeline!
• deduplication — The previous implementation wasn't deduplicating the events handled by the pinned-events cache. Now it's supported with the deduplicator module!
• better redaction — Redaction was working… by… mistake let's say. Or it wasn't working entirely. Redaction was handled by the room cache, but not by the pinned-events cache. Because the SQLite backend for the EventCacheStore uses a single table for all the events, when the room cache was redacting an event, it was redacted for all the caches. Solid, good, except the pinned-events cache had an unredacted event in memory! Every in-memory modification is broadcasted to the database, but the opposite direction is not supported. Now, redactions are handled like any other caches, both in-memory and in-database. (Note: all these features will be refactored to be shared by all the caches once the “flattening” is over).

Known Caveats

Sync gaps are not resolved. This was already the case before, and it's not fixed here, but at least it makes it obvious by looking at the code. There is no pagination whatsoever with the pinned-events cache.

How do we resolve that? When the cache loads, for each pinned-event, /relations is called to fetch all its related events. It is efficient except that once the pinned-event cache is created, it stays in memory for the entire lifetime of the Client.

It means that if the pinned-events cache is loaded, then a couple of sync happens, no missing events, good, then a gappy sync: ha, too bad, maybe an event related to a pinned-event is missing.

Solution 1: Generalise the “shriking when no more subscribers” mechanism we have for the room cache, and extend that on the pinned-events cache so that we can reload its state from the network.

Solution 2: When the pinned-events cache detects a gap in the sync (now it's easy, it has its own handle_sync method), we must reset its state by relying on the network only. I personally prefer this solution. A bit bazooka for a fly, but it will be the most reliable for the moment.

Thoughts?

• Address [meta] Event Cache layers refactoring #6152
• Sequel of feat(sdk): Flatten the hierarchy of caches in the Event Cache, part 1: Thread #6517

• I've documented the public API Changes in the appropriate CHANGELOG.md files.
• This PR was made with the help of AI.